1. Field of the Invention
The present invention relates to cryptography configuration. More particularly, the present invention relates to method and apparatus for controlling the use of cryptography such that products utilizing these controls may be exported in accordance with United States export laws, and/or imported into other countries that place additional restrictions on the use of cryptography.
2. Description of the Related Art
There are many circumstances where the distribution or the use of encryption software is regulated by governments. In some countries, the strength of encryption that can be exported is regulated without imposing any restrictions upon the distribution of the encryption software within the country. For example, in the United States, companies are frce to distribute any type of encryption software developed within the country for use by United States citizens. Furthermore, United States allows unrestricted importation of encryption technology. However, exporting of a certain strength encryption in the United States is regulated. In other countries, such as France, the strength of encryption that can be used, distributed or imported is tightly regulated.
In the case where the exporting of the encryption software is restricted, the permissible exportable encryption software are usually limited to specific algorithms that use key sizes which are weaker than a particular size. Previously, the encryption software has generally been an integral part of a software application. Therefore, to accommodate the varying degrees of allowed encryption levels, several versions of the same application are typically created; one version that provides strong encryption by those who are allowed unrestricted use, and one or more versions that use weaker encryption for those customers whose use is restricted. In many cases, one single weaker version is created to avoid the expense of creating and maintaining multiple versions of the same application.
One reason that applications distributed under these restricted rules have been required to include encryption modules as an integral part of the software, rather than as a separate module that can be plugged into the application, is to prevent an encryption module that supports strong encryption from being plugged into an application and used in a country where encryption is restricted, and thereby enabling strong encryption with that application.
Exportable/export strength encryption refers to encryption algorithms and key sizes that provide relatively weak (i.e., easy to defeat) protection of information. Presently, the United States government allows general purpose encryption products to be exported from the United States to other countries only if those products utilize approved encryption algorithms and key sizes that are weaker than a certain measure. General purpose encryption is an application of encryption that does not limit the type or size of the data being encrypted. The United States government places more restrictions on software that can encrypt any kind of data than it does on software that limits the type and size of the data being encrypted. SSL and S/MIME are considered to be general purpose encryption protocols because they do not place any limits on the type or size of the data being encrypted.
By contrast, special purpose encryption is an encryption application that limits the type and size of the data being encrypted. The United States government will sometimes give export permission for stronger encryption algorithms if they are limited in use to a specific purpose and type of data (strong encryption defined as encryption algorithms and key sizes that are stronger (i.e., harder to defeat) than those that the United States government usually allows to be exported for general purpose encryption). The SET protocol is an example of an encryption protocol that was designed to encrypt special purpose data for purposes of performing financial transactions only.
Recently, standards have been developed that define the interfaces between application software and modules that provide encryption. The purpose of these standards is to facilitate the use of Smart Cards and other hardware encryption devices. By defining a standard interface, and allowing encryption modules to be plugged into applications, any encryption module can be used with any application without having to write special software to integrate each module with each application.
The advent of these new standards presents a problem for application developers since applications that support pluggable encryption modules will be difficult or impossible to distribute under the current varying government regulations. In order to obtain the benefits of standards for pluggable encryption modules, an approach is necessary that satisfies governments by way of ensuring that their various levels of restrictions will be enforced. Such an approach will allow the application to be distributed separately from any encryption modules that it may use, but still allow the application to restrict the use of encryption to the permissible level.
One approach has been developed by Microsoft for their Crypto API (CAPI) system. Applications that use CAPI may only load encryption plugin modules that have been digitally signed by Microsoft. Microsoft will only sign a module once the developer of the module has agreed to abide by the governmental restrictions when distributing the module.
However, this approach poses several new problems. First, it requires a legal agreement between Microsoft and all developers of encryption modules, which can be expensive and time consuming. Another problem with the CAPI system is that it does not allow the application to access stronger encryption algorithms that may otherwise be available in the encryption plugin for those cases where only special purpose encryption is being performed for higher level of encryption-transactions, and stronger encryption may be used legally. Some applications that would benefit from or require this type of access are: Secured Socket layer (which are exportable cipher suites that have 40-bit secret keys still use 128-bit RC2 or RC4 encryption, where the 40 bits of the 128-bit key are secret while the remaining 88 bits are not.); Special purpose encryption protocols such as SET (these protocols limit the scope and the size of the data that they encrypt, so that most governments allow them to use much stronger encryption algorithms and key sizes than would be allowed for general purpose encryption); and encryption of key material (generally, when key material is being encrypted, strong algorithms and larger key sizes can be legally used).
As previously discussed, because the level of permissible exportable cryptography varies depending upon the importing country, different versions of a single application are necessary. Also, these different versions of the same application differ in languages used in the manuals and in the help files that are part of the product. In the past, a separate version of the single application was developed for each market, embodying the legally marketable cryptographic policies, for sale and use of the application in the target market. Each of these different versions had to be separately built, tested, localized (translated into the local languages), and supported. The cost of these operations is considerably greater than if there was only one single version of the application to serve all the markets. Having a single application for all these markets can also reduce development and testing time, therefore, shorting the time between development and testing of a new application to marketing and sale.
As discussed above, to address the multiple-version issue, some manufacturers and developers only make and sell products that contain no cryptography, while others only make and sell products that contain only the weaker exportable forms of cryptography, the latter foregoing making stronger cryptography available inside the United States (where stronger cryptography is not subject to export regulations). There are also manufacturers and developers that make separate version of the same program for each of the differing markets, and bear the expense and time-to-market cost associated with making and supporting multiple versions of the same application/product.
With any of the aforementioned approaches, many customers including banks and financial institutions find the weaker level of security offered as exportable general purpose encryption to be unacceptable for financial transactions. Additionally, building separate programs substantially increases time and expenses in production, quality testing, and support for the products.